refactor(core): drop retired execute permission mode from capability audit - #3603

Reviewed at exact head ec26f69bf40c6d98c0bd619ae62505c3247ad84f. No [P0]–[P3].

The change to watch here is executableScheduledTaskCount, because the predicate is rewritten rather than merely narrowed:

// before
scheduledTasks.filter((task) => task.permissionMode === 'execute')
// after
scheduledTasks.filter((task) => task.enabled && task.permissionMode !== 'explore')

Those select the same set, and it's worth writing down why, since the two expressions look nothing alike. enabled is derived as task.status === 'active' (scheduledTaskToAuditRecord), and explore is returned exactly for completed and expired. So the new predicate is active && not (completed | expired), which reduces to active. Under the old code, execute was returned for everything that was neither completed/expired nor paused — also active. Same membership, no drift in the reported count.

I checked specifically whether paused tasks could slip into the new count, since they map to ask and ask !== 'explore'. They can't: paused is not active, so enabled is false and the first conjunct rejects them.

The claim in the new comment — that the retired execute mode folded to ask identically — is consistent with execute having already been removed as a permission mode at the protocol layer, so no live caller can still be distinguishing the two.

The Exclude<CapabilityAuditPermissionMode, 'execute'> on SkillAuditRecord.permissionMode becomes redundant once execute leaves the union, and dropping it is correct rather than a widening: the field's producer at :146 only ever emits 'ask' or 'explore'.

CI note: this head's workflow run sat at action_required because it comes from a fork; I approved the run so it could execute. Gate conclusions should be drawn from that run's terminal state, not from this comment.

Reviewed at exact head 0b1d82097f175df3ada48ea830efdeff49306e3e (biome-formatting follow-up to ec26f69bf4; the delta is line-wrapping only). No [P0]–[P3].

What this pass verified beyond the earlier review:

• No remaining execute consumers in the audit surface. CAPABILITY_AUDIT_PERMISSION_MODES / CapabilityAuditPermissionMode are referenced only inside capability-audit.ts. The report's UI consumers (capability-audit-strip.tsx, module-pages.tsx, skills-panel.tsx) read neither permissionMode nor executableScheduledTaskCount, so nothing downstream still branches on the dropped value.
• No old-data read path can crash. The audit report is derived live (deriveCapabilityAuditReport over in-memory ScheduledTasks) and is never persisted under this enum. Persisted task templates go through the pre-existing decodePersistedScheduledTask fold (scheduled-task.ts), which maps a stored execute to ask via decodePersistedPermissionMode (permission.ts) — untouched by this PR.
• The folding claim is backed in-repo. RETIRED_PERMISSION_MODES in packages/core/src/permission.ts documents that execute compiled to the same profile as ask, which is exactly what the new comment asserts.
• executableScheduledTaskCount membership re-derived independently. Over SCHEDULED_TASK_STATUSES = active | paused | completed | expired: old predicate (permissionMode === 'execute') selected active only; new predicate (enabled && permissionMode !== 'explore') also reduces to active (paused fails enabled). Same count, and paused cannot slip in.

Gate: test is the only path-filtered check this change can trigger (no package.json/lockfile change, no sandbox/filesystem-worker paths) and it is terminal green on this exact head.

Reviewed on exact head 0b1d82097f175df3ada48ea830efdeff49306e3e. No findings.

Retiring a permission mode has two ways to go wrong, and both were checked rather than assumed:

Leftover consumers. 'execute' has no remaining consumer on the audit surface — the enum is referenced only within its own file, and the UI consumers read neither permissionMode nor executableScheduledTaskCount.

Old configs crashing on read. There is no such path here. The audit report is computed live from in-memory ScheduledTask values and never persisted, and persisted templates go through decodePersistedScheduledTask, which this PR does not touch and which still folds execute → ask via RETIRED_PERMISSION_MODES in permission.ts. So durable data written before this change still decodes.

The executableScheduledTaskCount predicate was also reduced independently on both sides and comes out the same: status === 'active', with paused excluded either way.

Gating: only test is triggered on this head — no package.json/lockfile changes and no sandbox paths, so audit and the Windows sandbox lane are correctly absent rather than missing. test is terminal success on the exact head.